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1 .  Abstract 

This  document  examines  the  potential  for  enhancement  of  Defence  Research  and  Development  Canada’s 
Collaborative  Operations  Planning  System  (COPIanS)  technology  demonstration  software  in  the  areas  of 
collaboration  and  data  visualization  using  IDELIX’s  Pliable  Display  Technology.  In  particular,  it  begins  by 
outlining  several  possible  forms  of  general  collaboration  that  apply  to  the  application  and  then  defines  a  number 
of  areas  within  the  application  with  collaboration  and  data  visualization  improvement  potential.  Each  of  these 
areas  is  subsequently  analyzed  in  depth  with  specific  details  of  how  enhanced  collaboration  and  data 
visualization  can  be  attained  with  PDT.  Finally,  rough  orders  of  magnitude  are  provided  for  all  defined  features 
and  potential  implementation  approaches. 
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2.  Introduction 

The  purpose  of  this  document  is  to  outline  how  the  Collaborative  Operations  Planning  System  (COPIanS), 
developed  by  Defence  Research  and  Development  Canada  Valcartier  (DRDC  Valcartier),  can  be  enhanced 
through  the  use  of  improved  collaboration  techniques  and  visualization  methods  using  IDELIX’s  Pliable  Display 
Technology  (PDT). 

It  is  assumed  that  the  reader  is  familiar  with  the  COPIanS  application  and  has  a  basic  understanding  of  how 
IDELIX’s  PDT  works. 
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3.  Potential  Enhancements  to  COPIanS 


3.1.  Collaboration 

Traditionally,  software  was  developed  with  a  single  user  in  mind.  However,  with  the  increase  in  network 
capabilities,  software  support  for  multiple  users  has  become  more  widespread.  A  major  difficulty  in  the  design  of 
such  software  is  that  the  requirements  for  a  collaborative  system  are  often  quite  different  than  those  for  a  single 
user  system.  Designing  software  for  a  collaborative  environment  is  difficult. 

When  considering  collaboration  in  the  design  of  a  software  system,  it  is  useful  to  realize  that  there  are  different 
kinds  of  collaboration  that  may  be  supported.  These  kinds  of  collaboration  lie  along  two  axes,  namely  time  and 
space,  with  two  values  along  each  axis  resulting  in  4  different  collaboration  scenarios  (see  Figure  1  below). 
Supporting  collaboration  in  these  different  situations  often  requires  differences  in  design. 


A 


a; 

£ 


Place  - 

Figure  1  -  Different  Kinds  of  Collaboration 

Some  examples  of  collaboration  that  fit  into  the  4  categories  are: 

1 .  Same  time,  same  place: 

a.  Users  working  together  on  a  tabletop  display. 

b.  Users  working  together  on  an  electronic  whiteboard. 

c.  Users  gathered  around  a  single  computer. 

2.  Same  time,  different  place: 

a.  Users  working  on  their  individual  computers,  collaborating  over  the  internet. 

b.  Users  working  on  their  individual  computers,  talking  on  the  phone. 

3.  Different  time,  different  place: 

a.  Users  sending  email  to  one  another  asking  questions  about  a  project. 

b.  Users  copying  files  over  to  a  central  repository,  to  be  accessed  later  by  somebody  else  at  a  different 
location. 

4.  Different  time,  same  place: 

a.  Users  leaving  notes  on  a  tack-board  for  one  another. 

b.  Users  drawing  comments  on  a  large  printed  diagram,  to  be  seen  later  by  somebody  else. 

3.2.  Collaboration  in  COPIanS 

The  COPIanS  system  is  a  very  complex  piece  of  software,  supporting  a  very  complex  planning  process  involving 
many  people.  Currently,  activities  such  as  on-line  planning,  video  teleconferencing,  on-line  chatting  and  on-line 
white  boarding  are  all  supported  by  the  application  while  future  versions  will  potentially  add  interactive  war 
gaming,  mission  rehearsal  and  synthetic  environments  to  the  list  of  its  collaborative  features.  However,  the 
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different  time 
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same  time 
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same  time 
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model  for  COPIanS  interaction  seems  to  be  based  upon  the  interaction  model  that  existed  prior  to  the 
development  of  the  COPIanS  system.  An  attempt  has  been  made  for  established  real-world  interactions,  be  they 
voice  communication,  paper-based  notes,  or  computer-based  communications,  to  have  equivalents  designed 
into  the  COPIanS  system.  For  example,  maps,  which  may  have  previously  existed  as  large  paper  maps  or 
electronic  maps  shown  on  a  dedicated  computer  viewing  system,  are  shown  in  their  own  sub-window  in 
COPIanS. 

Modeling  COPIanS  interactions  on  previously  established  interactions  is  extremely  valuable  in  order  to  allow 
users  to  adjust  to  the  system.  However,  a  designer  must  be  careful  to  not  abandon  previously  available,  and 
potentially  critical,  forms  of  collaboration.  For  example,  it  is  possible  for  several  people  to  gather  around  a  large 
paper  map  pinned  onto  a  wall  and  discuss  a  problem  but  it  is  much  more  difficult  for  multiple  people  to  gather 
around  a  small  computer  monitor.  The  affordances  of  these  two  systems  are  remarkably  different,  meaning  they 
naturally  encourage  and  support  different  types  of  behaviour.  When  affordances  differ  between  a  predecessor 
system  and  a  successor  system,  a  designer  must  design  the  new  system  in  such  a  way  as  to  make  up  for  lost 
capabilities. 

It  is  thus  desirable  for  special  collaboration  capabilities  to  be  built  into  COPIanS.  These  capabilities  could  be 
used  to  mimic  or  compensate  for  lost  collaboration  capabilities  not  naturally  supported  by  the  COPIanS 
interaction  model.  These  capabilities  could  also  make  possible  new  forms  of  collaboration  that  were  not  possible 
prior  to  the  existence  of  COPIanS. 

3.3.  Natural  COPIanS  Collaborative  Capabilities 

The  basic  COPIanS  architecture  is  based  on  a  centralized  database  of  knowledge  that  is  accessible  to  all 
interested  users.  This  architecture  naturally  supports  two  of  the  kinds  of  interaction  shown  in  Figure  1,  namely 
the  two  cases  where  collaboration  is  distributed  across  time.  Since  data  is  stored  centrally,  changes  made  by 
one  user  are  automatically  made  available  to  other  users  who  access  the  data  later.  The  centralized  data  store 
is  constantly  up  to  date,  and  regardless  of  what  point  in  time  a  user  logs  on,  they  are  up  to  date,  and  ready  to 
work. 

Since  collaboration  across  time  is  naturally  supported  by  the  existing  COPIanS  architecture,  it  is  useful  to  focus 
on  the  current  weak-point  of  COPIanS,  namely  simultaneous  collaboration,  either  in  one  place,  or  spatially 
distributed.  Simultaneous  collaboration  is  a  capability  that  is  not  naturally  supported  by  the  COPIanS 
architecture. 

3.4.  COPIanS  Enhancement  Options 

Below  are  a  number  of  areas  where  COPIanS  can  potentially  be  enhanced  as  well  as  a  subset  where  PDT  can 
assist  with  collaboration  by  providing  improved  visualization  of  the  information  being  presented: 

•  General  Visual  Collaboration 

•  PDT  in  the  COPIanS  GIS 

•  PDT  in  the  COPIanS  GIS  Operating  on  a  Collaboration  Tabletop 

•  Enhancing  the  Visual  Diagramming  Components  of  COPIanS 

o  Workflow  Management  (Workflow  Diagrams) 
o  Mission  Analysis  (Effect  Based  Diagrams) 
o  Order  of  Battle  Asset  Visualization  (ORBAT  Charts) 

4. 
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5.  General  Visual  Collaboration 


5.1.  Visual  Highlighting  Approaches  for  Multiple  Users 

A  number  of  approaches  to  providing  visual  highlighting  for  collaboration  purposes  among  multiple  users  are 
discussed  below.  The  approaches  range  from  the  simple  use  of  remote  cursors  to  the  more  complex 
use  of  a  universal  annotation  tool. 

5.1.1.  Remote  Cursors 

When  multiple  users  are  working  simultaneously,  but  remotely,  they  may  need  to  develop  an  awareness  of  what 
the  remote  users  are  doing.  This  can  be  done  by  showing  cursors  of  remote  users  moving  over  the 
screen  of  a  local  user.  A  local  user  would  have  his  own  cursor  with  which  to  interact  with  data,  but 
he  would  also  see  “ghost”  cursors  representing  the  current  actions  of  remote  users.  However,  a 
question  arises  as  to  what  to  show  when  the  screen  content  of  a  local  user  is  different  from  that 
being  shown  on  a  remote  user’s  desktop.  For  example,  a  remote  user  may  be  working  on  a  map, 
while  the  local  user  may  not  have  the  map  visible.  Thus,  it  is  proposed  that  a  remote  user’s  cursor 
only  be  shown  if  the  cursor  is  over  content  that  is  currently  visible  to  the  local  user. 

5.1 .2.  Multi-User  Radar  View 

Cursors,  as  previously  described,  can  give  some  level  of  awareness  as  to  the  actions  and  intentions  of  remote 
users.  There  are  also  other  ways  to  promote  awareness.  One  way  is  to  offer  a  sort  of  “awareness 
map”  that  displays  the  locations  of  multiple  users  in  a  large  display  space,  such  as  a  map.  When 
remote  users  are  collaborating  simultaneously  in  a  large  display  space,  they  will  frequently  navigate 
to  different  parts  of  the  display  space.  This  can  result  in  confusion  if  they  assume  that  they  are 
looking  at  the  same  area.  A  map  of  the  entire  display  space  with  individual  rectangles  indicating 
individual  user  locations  can  be  used  to  communicate  to  different  users  the  views  of  their 
collaborators.  This  reduces  confusion,  improves  efficiency,  and  reduces  the  occurrence  of  errors. 

5.1.3.  Awareness  Lenses 

Lenses  could  be  used  for  promoting  awareness  of  the  actions  of  remote  users.  In  much  the  same  way  as 
cursors  were  suggested  for  use  above,  lenses  would  provide  a  local  user  with  hints  as  to  what 
remote  users  were  doing.  Two  advantages  of  using  lenses  are  the  fact  that  lenses  can  provide  a 
detailed  view  of  the  actions  of  remote  users  and  a  local  user  would  be  unlikely  to  confuse  his  cursor 
with  a  remote  controlled  lens. 

5.1.4.  Universal  Annotation 

When  multiple  users  are  working  together  remotely,  whether  simultaneously  or  at  different  points  in  time,  it  is 

often  useful  to  be  able  to  make  ad-hoc  comments  regarding  any  part  of  the  data  being  operated  on. 
This  commentary  can  take  any  form.  Therefore,  it  is  desirable  to  provide  absolute  flexibility  in  what 
form  these  comments  can  take.  It  is  suggested  that  COPIanS  offer  the  capability  of  marking  up  data 
with  “virtual  crayons”  that  function  as  crayons  would  on  a  piece  of  paper.  A  user  could  scribble  text 
or  diagrams  anywhere  within  the  context  of  the  data.  These  notes  could  then  be  accessed  by  any 
other  user  and  possibly  deleted  or  modified  by  other  users  as  well. 

5.1.5.  Central  Note  Board 

A  central  shared  note  board  could  be  used  for  making  comments  that  need  to  be  read  by  other  users  but  do  not 
fit  into  any  of  the  standard  workspaces  for  whatever  reason. 

5.2.  Synchronization  Approaches  for  Two  Users 

5.2.1.  Multi-User  Master/Slave  Synchronization 

Sometimes  it  can  be  desirable  for  two  remote  users  to  have  their  remote  applications  tied  together.  In  this 

situation  the  two  applications  would  be  in  identical  states  at  all  times.  The  two  users  would  be  able  to 
either  simultaneously  control  the  workspace,  or  pass  control  to  one  another  using  some  protocol. 
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Synchronization  of  this  sort  serves  to  minimize  confusion  and  can  be  useful  if  one  user  wants  to 
provide  a  second  remote  user  with  a  “walk-through”  of  a  situation. 

The  mechanism  for  synchronizing  two  systems  can  take  one  of  two  forms.  In  the  first  form,  the  slave  machine 
would  be  a  dumb  display  host,  essentially  receiving  screenshots  over  the  network  from  the  master. 
The  main  advantage  to  this  approach  is  that  it  is  relatively  easy  to  implement  while  the  main 
disadvantage  is  that  it  is  highly  bandwidth  dependent.  The  alternative  is  for  the  two  systems  to  be 
synchronized  via  messaging  of  the  application  state.  System  state  synchronization  could  be 
achieved  by  sending  mouse  events  over  the  network  or  by  explicitly  setting  the  state  of  application 
components.  The  advantage  of  this  approach  is  conservation  of  bandwidth  while  the  disadvantage  is 
the  complexity  of  the  synchronization  process. 

5.2.2.  On-Demand  Synchronization 

While  the  previous  example  dealt  with  prolonged  system  synchronization,  it  could  be  useful  to  have  the  option  of 
performing  a  one-time  system  synchronization.  In  this  scenario,  a  user  would  request  the  software 
to  synchronize  to  the  state  of  a  remote  collaborator.  The  system  would  immediately  put  the  software 
in  a  state  identical  to  that  of  the  collaborator.  Immediately  after  this  action,  however,  control  would 
be  returned  to  the  user  and  the  user  would  be  free  to  navigate  away  from  this  original  state  without 
any  impact  on  the  state  of  the  remote  collaborator’s  system.  This  function  would  be  useful  if  two 
collaborators  wanted  to  start  with  the  same  initial  state  but  then  wanted  to  work  in  parallel. 

5.3.  Architectural  Considerations 

The  example  collaboration  scenarios  described  above  require  that  COPIanS  be  able  to  provide  efficient 

communication  between  users,  made  possible  by  efficient  communication  between  users’  machines.  In 
order  for  awareness  to  be  improved,  tools  such  as  remote  cursors,  awareness  lenses,  and  others 
necessitate  up  to  date  display  of  relevant  data.  If  components  meant  to  promote  awareness  and 
collaboration  are  out  of  date,  due  to  bandwidth  or  latency  issues,  awareness  and  collaboration  may  in 
fact  be  hampered. 

There  are  two  main  possibilities  when  considering  communication,  either  a  TCP/IP  based  client/server 
architecture  or  a  TCP/IP  based  peer-to-peer  architecture.  Considering  the  existing  COPIanS 
architecture,  which  is  client/server,  it  would  seem  natural  for  collaboration  functions  to  also  be 
client/server  in  nature.  In  fact,  this  would  be  ideal  for  such  suggested  functionality  as  the  central  note 
board,  universal  annotation,  remote  cursors,  and  multi-user  radar  views.  All  of  these  examples  can 
potentially  involve  many  users,  rather  than  just  two.  A  peer-to-peer  architecture  would  also  be  possible 
but  would  require  a  web  of  many  constantly  open  network  connections.  Also,  a  centralized  client/server 
architecture  would  minimize  the  need  for  complicated  synchronizations.  It  is  useful  to  note  that  a 
centralized  client/server  architecture  puts  great  reliance  on  reliable  connections.  It  should  be  safe  to 
assume  reliable  networking  for  the  purpose  of  the  proposed  collaboration  functionality,  since  reliable 
networking  would  be  a  requirement  for  basic  functioning  of  COPIanS  anyway. 

For  the  case  of  functionality  involving  only  two  users,  such  as  on-demand  synchronization  and  master/slave 
synchronization,  a  client/server  architecture  is  not  such  a  clear  choice.  For  this  functionality,  a  central 
server  would  only  serve  to  insert  an  extra  step  in  communication,  which  could  be  an  unnecessary 
performance  bottleneck.  For  two-user  collaboration,  a  direct  peer-to-peer  connection  may  be  more 
appropriate.  Response  time  would  be  faster,  and  bandwidth  could  possibly  improve. 
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6.  PDT  in  the  COPIanS  GIS 


The  amount  of  information  available  to  the  war  fighter  has  increased  dramatically  in  recent  years.  This  increase 
in  the  quantity  of  information  has  not  necessarily  led  to  improved  situational  awareness  and  better  decision¬ 
making.  The  complexity  of  the  modern  battlefield  is  such  that  problems  of  interoperability,  collaboration, 
correlation,  fusion,  and  overload  are  replacing  the  old  problem  of  insufficient  information. 

One  of  the  key  functionalities  offered  by  COPIanS  is  a  GIS.  In  using  the  GIS  the  resolution  of  an  image  often 
exceeds  that  of  the  display.  Information  is  seemingly  lost  as  data  is  taken  out  of  context  by  traditional 
viewing  methods  such  as  zooming,  panning,  or  using  separate  or  inset  views.  Each  of  these  approaches 
disconnects  the  area  of  interest  from  the  underlying  information,  thus  inviting  errors  in  interpretation.  As  data 
density  continues  to  increase  and  display  screens  get  smaller,  innovations  in  visualization  software  and  data 
interaction  are  necessary  to  ensure  timely,  accurate  military  decisions  are  being  made. 

Using  a  magnifying  lens  metaphor,  detail  appears  within  the  center  of  the  PDT  focal  region  and  blends  smoothly 
into  the  background  context  using  the  lens  periphery  or  shoulder.  Once  PDT  is  integrated  within  a  host 
application,  tools  commonly  used  to  perform  editing,  annotation,  or  other  data  interaction  functions  can  be 
applied  with  complete  accuracy  to  the  information  appearing  within  the  lens.  PDT  replaces  recurring  zooming 
and  panning  steps  and  the  use  of  inset  windows  that  result  in  workflow  inefficiencies  and  important 
information  being  pushed  off  the  screen  or  hidden  from  view.  Additionally  PDT  facilitates  new  visualizations 
such  as  area  specific  blending  and  collaboration. 


Figure  2  -  Cluttering  of  the  GIS  Mission  Planning  Map 
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6.1.  On-Map  Mission  Planning 

The  GIS  mapping  tool  is  one  of  the  most  essential  components  of  the  COPIanS  application  since  much  of  the 

Coarse  of  Action  (COA)  sketching  and  planning  is  map-based.  Viewing  stacks  of  GIS  layers  and  military 
symbols  can  make  the  screen  appear  cluttered  and  confusing  (see  Figure  2  above).  Existing  zooming 
and  panning  tools  don’t  properly  address  the  need  to  analyze  a  detailed  region  of  interest  on  a  map  and 
understand  how  this  detail  relates  to  the  context  of  the  surrounding  image.  Standard  inset  views  are  also 
highly  problematic  in  that  they  hide  information  and  break  visual  continuity  with  the  surrounding  context 
outside  the  area  of  interest. 

6.2.  PDT  Enhancement  of  On-Map  Mission  Planning 

The  benefits  of  integrating  PDT  into  the  GIS  component  of  the  COPIanS  application  are  numerous  and 

compelling.  First,  PDT  extends  traditional  zoom  and  pan  capabilities  by  allowing  users  to  view  detail 
within  a  region  of  the  map  without  loosing  a  view  of  the  surrounding  context.  The  magnified  area  and  the 
background  map  remain  seamlessly  connected.  Second,  PDT  can  help  users  view  multi-layer  GIS  data 
while  conserving  communication  bandwidth  between  the  application  viewer  and  the  base  GIS  data.  To 
reduce  data  download  time  the  PDT-enhanced  application  would  only  request  data  for  the  relevant  area 
of  interest  (i.e.  the  area  currently  covered  by  the  lens).  The  integration  of  PDT  also  makes  it  possible  to 
view  different  layers  and  combinations  of  layers  within  the  lens  from  the  layer  being  displayed  in  the  base 
image.  Finally,  PDT’s  unique  “undisplace”  feature  permits  accurate  distance  measurement  and  symbol 
placement  within  a  PDT  lens  thereby  eliminating  time  consuming  and  inefficient  zooming  and  panning. 

The  following  sections  describe,  in  detail,  PDT  related  functionality  that  can  potentially  be  integrated  into  the  GIS 
component  of  the  COPIanS  application. 
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Figure  3  -  PDT  Lens  on  a  Map 
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6.2.1.  PDT  Lens  Providing  Focus  plus  Context 

PDT  is  a  powerful  alternative  to  existing  zooming  and  panning  tools.  PDT  lenses  represent  an  enhancement  to 
the  GIS  client  application  user  interface  for  rapid  exploration  of  large  geo-spatial  areas  and  for 
providing  local  detail  with  full  situational  awareness  without  hiding  information.  PDT’s  user  interface 
provides  the  user  with  direct  and  intuitive  control  over  the  presentation  of  data  within  the  lens  (see 
Figure  3  above). 

6.2.1. 1.  Lens  Control 

The  following  PDT  lens  controls  can  be  implemented: 

•  Modular  Design  Lens  Control  (MDLC)  including  magnification  slider,  scoop  slider  and  user  resizing  via  point, 
click  and  drag. 

The  end  user  would  be  able  to  change  the  parameters  of  each  lens  by  using  the  associated  MDLC,  independent  of 
other  lenses  on  the  same  image.  The  end  user  would  be  able  to  configure  each  occurrence  of  the  lens  as 
follows: 

•  MDLC  controls  are  always  visible 
•  MDLC  controls  are  only  visible  when  lens  is  selected 

6. 2. 1.2.  Lens  Shapes  and  Lens  Creation 

First,  the  following  PDT  lens  shapes  can  be  implemented  and  made  selectable  by  the  end  user  when  the  lens  is  being  added 
to  an  image. 


•  Pyramid 
Cone 
Square 

i  shape  of  an  existing  lens  can  be  configured  to  be  changeable.  Third,  when  a  lens  is  selected  it  can  be  made  to  appear 
tically  centred  on  the  screen  viewing  area  of  the  image.  In  addition,  it  is  possible  to  enable  the  end  user  to  pre-configure  the 
ze,  magnification  level,  MDLC  colours,  scoop  setting)  since  these  settings  are  saved  on  the  target  machine  and  applied 
to  all  users  and  images.  Also,  when  a  lens  is  subsequently  placed  on  an  image,  the  lens  can  be  sized  as  per  the  “pre- 
red  size”  as  described  above.  Finally,  the  end  user  can  be  allowed  to  selectively  remove  each  lens  uniquely  from  an  image. 

dering  Options 

:t  to  image  rendering  the  user  can  be  given  control  over  image  warping,  image  shading  and  image  anti-aliasing.  The  three 
options  for  image  warping  are  the  triangle,  fast  and  pixel  warpers.  The  triangle  image  warper  produces  a  more  accurate  and 
detailed  image  than  the  fast  image  warper.  However,  on  computers  with  slow  CPU’s  the  motion  of  the  lens  can  be  jerky 
when  using  the  triangle  image  warper.  Thus,  in  order  to  improve  lens  response  while  it  is  being  moved,  the  fast  image 
warper  should  usually  be  used  in  these  situations.  Both  image  shading  and  image  anti-aliasing  can  be  either  turned  on  or 
turned  off. 

ler  to  provide  a  set  of  user-friendly  controls  over  image  rendering,  the  following  image  warping,  shading  and  anti-aliasing 
options  can  be  implemented: 

jality  (using  pixel  image  warping,  shading  and  anti-aliasing, 
ality/Performance  (using  pixel  image  warping  only),  and 
ce  (using  fast  image  warping  only). 


ns 

lens  options  that  can  be  included: 
n  or  off  when  moving  lens 
ols  for  selected  lens 
:or  non-selected  lenses 
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jported 

ises.  These  lenses  can  highlight  multiple  areas  of  interest,  perform  precise  point-to-point  measurements  without  panning,  and 
on  (See  Figure  4  below). 


s  on  a  Map 


>e  supported  on  a  single  image.  The  only  limit  would  be  one  based  upon  the  amount  of  memory  on  the  user’s  computer. 


!  to  support  folding.  The  user  can  also  be  given  the  ability  to  “unfold  the  lens”  through  the  single  click  of  a  GUI  button. 

ile  a  Lens  is  on  an  Image 

tool  can  be  maintained.  In  addition,  when  an  image  is  panned,  the  PDT  lens  can  be  configured  to  remain  locked  to  the  image 
eked  to  the  screen  where  placed,  or  disappear. 

lile  a  Lens  is  on  an  Image 

n  tool  can  be  maintained.  Also,  when  one  or  more  PDT  lenses  are  on  an  image  and  the  user  globally  zooms  the  image,  the 
maintain  their  sizing  relative  to  the  screen.  In  addition,  when  the  image  is  zoomed,  the  magnification  of  the  lens  can  be 
he  image  within  the  lens  will  change  as  a  function  of  the  global  zoom  times  the  zoom  setting  of  the  lens.  And  finally,  when  an 
DT  lens  can  be  configured  to  remain  locked  to  the  image  where  placed,  locked  to  the  screen  where  placed,  or  disappear. 


lade  available  in  the  GIS  portion  of  the  application. 

)ility,  through  an  easy  to  use  Ul,  to  zoom  the  entire  image  to  the  scale  of  the  focal  region  of  a  PDT  lens. 
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1DLC  controls  can  be  rendered  invisible  with  an  indication  that  the  image  has  been  zoomed  in. 

Ilowed  to  increase  or  decrease  the  zoom  level  of  the  image, 
i  be  allowed  to  reverse  the  zoom  to  scale  operation  previously  executed, 
an  be  made  to  remain  operational. 

Bitioned  to  be  consistent  with  the  zoomed  in  image  and  the  MDLC  controls  can  be  made  visible, 
e  level  of  magnification  prior  to  zooming  out  even  if  the  user  had  changed  the  zoom  level  while  zoomed  to  scale. 


pically  faced  with  many  unnecessary  navigation  steps  when  using  these  tools  at  an  adequate  scale  for  precise  data  authoring. 
3DT,  where  symbols  can  be  “dropped”  into  place  precisely,  while  eliminating  the  need  for  zooming  and  panning.  PDT  speeds 
itial  production  workflow. 


the  user  to  perform  fully  precise  distance  measurements  spanning  a  large  extent  of  the  data  without  the  need  for  awkward 
length,  perimeter,  and  radius  measurements  within  the  GIS  application  can  similarly  benefit  when  the  measuring  tool  is 
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t  to  turn  on  and  off  a  shaded  snail  trail  (that  will  show  where  the  PDT  lens  has  been  on  the  image)  as  well  as  clear  the  snail 


r  rails 

t  to  drive  a  PDT  lens  to  automatically  and  sequentially  traverse  an  image  over  a  prescribed  path.  If  desired,  a  shaded  snail 
5  has  been  and  the  image  (including  the  snail  trail)  can  be  saved  so  that  the  user  may  return  to  the  image  at  a  later  date  to 


lology.  In  order  for  the  user  to  obtain  the  situational  awareness  of  the  battle  theatre  the  map  is  typically  zoomed  out  to  a  large 
ymbols  are  clustered  very  closely  together  and  often  overlap  each  other  as  well  as  occlude  parts  of  the  map  image.  By 
lap  of  smaller  scale  (for  example,  1 :50,000).  The  symbols  are  now  placed  on  the  smaller  scale  map  thus  reducing  the  visual 


nd  Transparency 

ap  viewer  by  linking  data  layer  selection  to  data  layer  visibility  within  the  PDT  lens.  This  can  be  accomplished  by  creating  user 
ed  to  data  layers  displayed  on  a  GIS  map  (see  Figure  6  below). 
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Dling  of  data  visible  outside  the  lens  with  data  visible  inside  the  lens.  As  such,  the  PDT  lens  can  be  used  to  de-clutter  the 
ne  second  is  the  ability  to  blend  layers,  with  varying  degrees  of  layer  transparency,  to  allow  for  better  interpretation  of  the 
ip  while  a  second  layer  was  a  geo-rectified  image  of  the  location,  a  user  would  be  able  to  more  quickly  and  precisely  locate 
;y  adjustments  were  provided. 


d  GIS,  to  collaborate  in  real  time.  A  lens  placed  on  one  occurrence  of  the  GIS  can  be  automatically  placed  on  a  second 
a  a  TCP/IP  based  network.  For  details  of  enablement,  see  the  section  4  discussions  on  synchronization  approaches  and 
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i  a  Collaboration  Tabletop 


>orting  remote  collaboration.  However,  local  collaboration  can  be  equally  important.  As  previously  mentioned,  standard 
jple  gathering  around  discussing  some  topic.  In  such  a  situation,  it  is  better  to  have  a  large  display  of  some  type,  either  a 
se  devices  driven  by  some  direct  interaction  such  as  a  pen,  a  stylus,  or  some  tactile  input,  and  it  is  desirable  for  the  system  to 
ires  all  serve  to  simulate  the  equivalent  functionality  of  a  whiteboard  or  paper  map.  Such  devices  currently  exist,  one  being 
Labs.  It  is  proposed  that  we  identify  the  functionality  within  COPIanS  that  would  benefit  most  from  supporting  naturally  co- 
n  an  appropriate  device. 


jected,  gesture-based,  light  table  called  the  DiamondTouch  Table  (see  Figure  7  below).  The  DiamondTouch  (DT)  Table  is  a 
)uch  events  on  an  individual  user  basis.  This  ability  makes  the  DT  Table  a  very  useful  device  in  the  area  of  human-computer 

is  embedded  in  the  touch  surface.  Each  antenna  transmits  a  unique  signal.  When  a  user  touches  the  surface,  the  antennas 
■ough  the  user's  body  to  a  conductive  pad  on  the  user’s  chair. 


;  on  a  single  surface, 
i  way  to  interact  with  geo-spatial  data. 

;an  be  deployed  into  a  forward  command  and  control  situation, 
le  has  no  effect  on  a  users  input  actions), 
red  with  projector,  stand,  carrying  cases  etc). 


'e  aspect  involving  multiple  users  and  where  one  (or  more)  large,  shared  display  surfaces  can  be  beneficially  used.  Typically 
iplines  must  come  together  in  order  to  produce  a  high  quality  output.  The  team  can  be  gathered  around  a  single  DT  Table  or 
ole.  Given  the  capability  of  theDT  Table,  it  is  well  suited  to  be  used  in  the  following  environments  and  applications: 
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ware  applications  available.  The  only  software  applications  that  exist  are  several  basic  programs  that  demonstrate  some  of 
;  insight  to  the  possibilities  of  using  the  DT  Table  in  a  military  environment  they  do  not  provide  sufficient  functionality  to  be  field 
;igned  from  inception  to  support  multiple  simultaneous  users  and  accept  multi  handed  gestures  as  input. 


i.  This  application  ingests  JPEG  imagery  and  displays  it  on  the  table.  Using  two  fingers,  one  from  each  hand,  a  user  can 
As  the  user  separates  their  fingers,  the  PDT  lens  can  be  sized.  The  users’  finger  is  then  used  to  move  the  le  ns  around  the 
ens.  The  user  can  also  select  a  pen  and  annotate  a  region  of  interest  by  drawing  on  the  table  with  a  finger. 


liven  the  fact  there  are  no  commercially  deployable  table  aware  (gesture-based,  multi-user)  applications  available,  we 
le  benefits  that  a  DT  Table  with  appropriate  software  can  offer.  Given  the  target  users  and  use  scenarios  identified  earlier  in 


iut  device  (such  as  the  DT  Table).  As  a  result  there  is  an  inherent  risk  associated  with  the  implementation  of  such  an 
:ation  technologies,  as  well  as  geo-spatial  expertise,  this  risk  can  be  mitigated. 

ible  aware  application  be  used.  The  first  phase  should  be  aimed  at  developing  an  initial  prototype  table  aware  application  that 
esired  functionality  can  be  obtained  and  documented.  Only  then  will  it  make  sense  to  develop  a  more  complete  prototype  or 
nd  users  and  thoroughly  evaluated  in  order  to  fully  understand  the  potential  benefits  prior  to  finalizing  any  subsequent 


;  possible  to  run  existing  PC  applications  on  the  table  and  use  a  mouse  paradigm  as  an  input  device,  the  true  benefits  of  the 
for  dual  hand  based  gesture  inputs  from  a  user  and  almost  all  software  programs  do  not  allow  multiple  simultaneous  users  to 
,  a  table).  What  is  required  is  a  multi-user  application  that  allows  the  use  of  hand  gestures  in  order  to  fully  exploit  the 
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aster  data  in  common  file  formats. 
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o  Straight  Line  -  distance  is  measured  in  a  straight  line  by  defining  a  start  and  stop  point, 
o  Polygon  -  distance  is  measure  by  following  a  polygonal  path  defined  by  the  user. 

7. 2. 6.7.  Tool  Bars 

•  Tool  bars  should  be  modular  with  logical  functions  grouped  together. 

•  Each  user  should  be  able  to  detach  a  tool  bar  of  choice  and  position  it  as  desired  on  the  table. 

•  The  tool  bars  should  be  colour  coded  so  that  they  can  be  associated  with  each  user. 

•  A  later  version  of  the  application  could  have  toolbars  that  can  orient  as  appropriate  to  the  position  of  the 
user,  but  this  is  challenging  to  implement  in  common  development  frameworks  and  will  require  additional 
effort. 

7. 2. 6.8.  Layers  and  Transparency 

•  Be  able  to  ingest  multiple  files  and  display  two  of  the  files  as  layers. 

•  Be  able  to  define  what  file  is  displayed  inside  the  lens  and  what  file  is  displayed  outside  the  lens. 

•  Be  able  to  change  the  transparency  of  the  layers  within  the  PDT  lens. 

7. 2. 6.9.  Remote  Collaboration 

•  The  application  should  support  collaboration  between  2  (or  more)  geographically  dispersed  tables  that 
are  connected  via  an  IP  based  data  link. 

•  It  should  be  possible  to  pass  control  from  one  table  to  another  table  at  the  option  of  a  moderator. 

•  Actions  on  the  control  table  should  be  copied  on  the  remote  table.  This  should  include  annotation  and 
mensuration  as  well  as  PDT  lens  configuration  and  movement. 

7.2.6.10.  Calibration 

The  application  should  have  a  calibration  routine  bundled  or  built  in  so  that  the  table  can  be  calibrated. 
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8.  Enhancing  the  Visual  Diagramming  Components  of  COPIanS 

This  section  examines  the  potential  for  enhancing  the  visual  diagramming  components  of  the  COPIanS 
application. 

8.1.  Workflow  Management 

The  Workflow  Diagram  component  of  COPIanS  (created  using  the  JViews  visual  diagramming  tool  from  ILOG) 
is  currently  used  to  create,  display  and  manage  relatively  simple  process  workflows  (see  Figure  8  below). 
However,  the  potential  for  the  creation  of  significantly  more  complex  workflows  does  exist.  Workflow  diagrams 
for  complex  decision  paths  can  quickly  grow  to  a  level  where  it  is  impractical  or  impossible  to  display  the  entire 
structure  in  a  single  window.  In  such  cases  users  typically  choose  zooming  and  panning  tools  to  view  a  portion  of 
the  diagram  at  a  “readable”  scale.  This  often  results  in  inefficiencies  and  a  loss  of  situational  awareness  as 
important  information  is  pushed  off  the  screen. 


Figure  8  -  Typical  Workflow  Diagram  in  COPIanS 


Also,  as  stated  in  the  DRDC  fact  sheet  (IS-228-A),  the  new  version  of  COPIanS  will  support  multi-level  workflows 
where  planners  will  be  able  to  define  activities  which  in  themselves  are  workflows  involving  a  subset  of  activities. 
The  ability  to  capture  conditional  workflow  processes  is  also  being  considered. 
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8.2.  Mission  Analysis 

The  Effect  Based  Diagram  component  of  COPIanS  (created  using  the  JViews  visual  diagramming  tool  from 
ILOG)  is  currently  used  to  display  and  modify  relatively  complex  process  workflows  (see  Figure  9  below)  used  for 
detailed  mission  analysis.  In  such  cases  users  typically  choose  zooming  and  panning  tools  to  view  a  portion  of 
the  diagram  at  a  “readable”  scale.  This  often  results  in  inefficiencies  and  a  loss  of  situational  awareness  as 
important  information  is  pushed  off  the  screen. 


Figure  9  -  Typical  Effect  Based  Diagram  in  COPIanS  for  Mission  Analysis 
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8.3.  Order  of  Battle  (ORBAT)  Asset  Visualization 

The  ORBAT  (Order  of  Battle)  browser  in  COPIanS  (created  using  the  JViews  visual  diagramming  tool  from 
ILOG)  allows  commanders  to  visualize  and  formulate  analysis  about  the  assets  and  resources  available  to  them 
for  a  given  task  (see  Figure  10  below).  Similar  to  Workflow  Diagrams,  ORBAT  charts  can  become  complex  and 
difficult  to  view  in  their  entirety  on  computer  screens. 


Figure  10  -  Typical  ORBAT  Chart  in  COPIanS 
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8.4.  Detail-in-Context  for  Visual  Diagramming  in  COPIanS 

Several  components  of  COPIanS,  specifically  the  Workflow  Diagrams,  the  Effect  Based  Diagrams,  and  the 
ORBAT  Charts  display  a  network  of  discrete  data  elements  connected  by  logical  relationships.  Logical 
relationships  are  communicated  to  the  user  visually,  using  position  and  connecting  symbols  such  as  arrows.  This 
data  is  inherently  different  from  the  type  of  data  usually  associated  with  PDT  enabled  applications.  Typical  PDT 
applications  deal  with  continuous  data  where  positional  relationships  are  inherent  in  the  data.  For  example,  map 
data  is  continuous,  and  objects  on  the  map  have  real-world  positions.  In  an  ORBAT  chart,  however,  the 
relationship  of  different  components  is  purely  logical,  and  how  those  relationships  are  shown  is  up  to  the  display 
process. 

While  detail-in-context  rendering  can  have  a  significant  positive  impact  in  viewing  discrete  networks  of  abstract 
data,  PDT  is  not  the  ideal  detail-in-context  approach.  Rather,  it  is  suggested  that  a  detail-in-context  approach 
designed  from  the  ground  up  for  viewing  of  networks  of  discrete  logically  related  data  be  employed.  Rather  than 
magnifying  data  in  a  continuously  varying  manner,  the  technique  would  magnify  individual  objects  independently 
without  distorting  any  one  discrete  object.  Logical  connections,  represented  by  lines  or  arrow,  would  not  be 
distorted  but  would  instead  simply  have  their  start  and  end-points  moved  to  accommodate  reshaped  objects. 
There  have  been  several  techniques  similar  to  the  one  described  developed  in  the  academic  community.  The 
differences  between  the  techniques  mostly  have  to  do  with  how  objects  are  moved  about  the  screen,  if  at  all,  and 
how  much  objects  are  magnified,  depending  on  their  relationship  to  the  object  of  interest. 

Perhaps  the  most  challenging  part  of  the  proposed  work  would  be  to  determine  which  technique  would  be  most 
appropriate  for  COPIanS.  This  may  be  further  complicated  by  the  fact  that  the  ORBAT  charts,  being  hierarchical 
data  sets,  may  benefit  from  a  different  detail-in-context  approach  than  the  other  components.  Hierarchies  are  a 
specialized  subset  of  general  network  graphs  and  detail-in-context  algorithms  can  be  fine  tuned  to  suit  this 
special  case. 
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9.  Rough  Order  of  Magnitude  (ROM)  Estimates  by  Feature 

This  section  provides  rough  order  of  magnitude  (ROM)  estimates  of  the  effort  required  to  implement  various 
collaboration  and  data  visualization  features  mentioned  in  the  preceding  discussions.  These  estimates  are 
provided  for  comparison  purposes  only. 

9.1.  General  Visual  Collaboration 

9.1.1.  Visual  Highlighting  Approaches  for  Multiple  Users 

9. 1.1.1.  Remote  Cursors 

•  Level  of  Effort:  Low 

•  Risk:  Medium 

•  Payoff:  Medium 

•  Priority:  Medium 

9. 1.1.2.  Multi-User  Radar  View 

•  Level  of  Effort:  Medium 

•  Risk:  Medium 

•  Payoff:  Medium 

•  Priority:  Medium 

9. 1.1.3.  Awareness  Lenses 

•  Level  of  Effort:  High 

•  Risk:  High 

•  Payoff:  High 

•  Priority:  Medium 

9. 1.1.4.  Universal  Annotation 

•  Level  of  Effort:  High 

•  Risk:  Medium 

•  Payoff:  High 

•  Priority:  High 

9. 1.1. 5.  Central  Note  Board 

•  Level  of  Effort:  Medium 

•  Risk:  Low 

•  Payoff:  Medium 

•  Priority:  Medium 
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9.1.2. 


Synchronization  Approaches  for  Two  Users 


9. 1.2.1.  Multi-User  Master/Slave  Synchronization  -  Dumb  Display  Host 

•  Level  of  Effort:  Medium 

•  Risk:  Low 

•  Payoff:  Medium 

•  Priority:  High 

9. 1.2.2.  Multi-User  Master/Slave  Synchronization  -  Application  Synchronization 

•  Level  of  Effort:  High 

•  Risk:  Medium-High 

•  Payoff:  Medium 

•  Priority:  Low 


9. 1.2.3.  On-Demand  Synchronization 


•  Level  of  Effort: 

•  Risk: 

•  Payoff: 

•  Priority: 


Medium 

Medium 

Low 

Low 
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9.2. 


9.3.  PDT  in  the  COPIanS  GIS  (Note:  Assumes  access  to  GIS  source  code) 

•  Level  of  Effort:  Medium 
•  Risk:  Low 

•  Payoff:  High 

•  Priority:  High 

.1.  PDT  Lens  Providing  Focus  plus  Context 

Level  of  Effort:  Low 
Low 

High 

High 

issisted  Functionality 

Low 

i / 

High 


g  Map 
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oration  Tabletop  (Note:  Assumes  access  to  table  aware  GIS  application  source  code) 
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9.5. 
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9.6.  Enhancing  the  Visual  Diagramming  Components  of  COPIanS 


9.6.1 .  Enhancement  of  Workflow  Diagrams 

•  Level  of  Effort:  TBD 
•  Risk:  TBD 

•  Payoff:  TBD 

•  Priority:  TBD 

.2.  Enhancement  of  Effect  Based  Diagrams  (Mission  Analysis) 

Level  of  Effort:  TBD 
TBD 
TBD 

TBD 

cement  of  ORBAT  Charts 

TBD 

0 

TBD 
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odels 


•oposed  and  properly  integrate  PDT  into  an  existing  application,  the  integrator  must  have  access  to  the  image  rendering 
ation.  While  this  type  of  integration  is  not  necessarily  difficult  it  must  be  done  with  full  access  to  the  image  processing  pipeline 
tion.  This  is  an  area  that  third  party  developers  have  not  traditionally  had  access  to.  Given  this  background,  the  following 
entified  and  will  be  referred  to  later  in  this  report. 

ired  Functionality 

iriginal  author  of  the  application,  integrates  PDT  using  the  SDK.  Since  the  OEM  owns  the  source  code  they  have  access  to 
application  in  order  to  properly  integrate  PDT.  The  obvious  benefit  of  this  model  is  that  the  architecture  and  implementation 
completely  understood.  The  downside  is  that  the  OEM  must  first  develop  a  detailed  understanding  of  PDT  and  then  define 
ition.  As  PDT  is  a  relatively  new  technology  and  most  OEMs  have  not  yet  been  exposed  to  it,  IDELIX  feels,  with  some  recent 
s  results  in  a  less  than  optimal  implementation. 

>  the  Image  Processing  Pipeline;  IDELIX  Integrates 

s  to  the  image-processing  pipeline.  Once  the  APIs  are  made  available,  IDELIX  can  proceed  with  the  integration  of  PDT.  The 
that  the  OEM  retains  control  of  its  product  and  does  not  need  to  expose  its’  source  code  to  an  external  integrator.  If 
3d,  it  is  expected  that  the  resulting  integration  would  be  of  high  quality.  However,  given  the  extensive  effort  involved  to  both 
irfaces  and  subsequently  implement  PDT  through  those  interfaces,  it  is  expected  that  this  model  would  be  relatively  expensive 


tly  Integrate  Required  Functionality 

vork  together  to  integrate  PDT  into  the  target  application.  Access  to  the  source  code  is  provided  to  IDELIX  with  the  resulting 
sting  the  initial  requirements  and  expectations.  The  primary  issue  here  is  usually  cost  since  two  companies  must  assign 
-located  geographically  to  be  most  effective.  The  resultant  travel  and  living  expenses  can  be  a  significant  additional  cost  to 
re  is  often  an  overlap  of  duties  between  the  two  organizations  that  can  increase  integration  costs  further. 

|uired  Functionality 

>  to  the  OEMs  source  code  and  performs  all  integration  of  PDT  into  the  target  application.  This  is  a  model  that  IDELIX  has 
it.  For  example,  this  method  was  used  for  the  integration  of  PDT  into  ITT's  Rapid  Access  Image  Viewer  (RAIV)  and  Mobile 
/)  clients.  Included  in  this  model  is  the  provision  of  time  for  IDELIX  to  transfer  to  the  OEM  the  knowledge  of  how  PDT  was 
ion.  This  is  typically  done  by  providing  both  SDK  related  training  and  a  detailed  code  review  explaining  where  and  how  PDT 
le  OEM  software.  Once  the  OEM  has  received  this  training  they  are  fully  capable  of  maintaining  the  code  base  while  IDELIX 
3  support  the  OEM  on  an  ongoing  basis.  However,  there  is  a  significant  risk  with  this  option  in  that  an  OEM  vendor  may  be 
;e  code  with  IDELIX  as  this  code  may  contain  part  or  all  of  their  core  intellectual  property. 

tegrator  Integrates  Required  Functionality 

tegrator  is  given  access  to  the  OEM’s  source  code  and  performs  all  integration  of  PDT  into  the  target  application  using  the 
main  issue  with  this  implementation  option  is  that  an  appropriate  third  party  vendor,  one  that  is  familiar  with  both  the  base 
K,  may  be  difficult  to  find.  Also,  as  stated  previously,  the  OEM  vendor  may  be  unwilling  to  share  their  source  code  with  the 


Application  to  Specification 

/v  application  that  is  both  compliant  with  the  required  functionality,  as  defined  by  the  customer,  and  has  integrated  PDT 
3  of  this  model  is  that  one  organization  has  control  over  the  development  of  both  the  core  functionality  and  the  integrated  PDT 
the  organization  that  will  be  the  most  familiar  with  the  PDT  SDK  and  its  implementation  challenges. 

tegrator  Produces  an  Application  to  Specification 

ntegrator  produces  a  new  application  that  is  both  compliant  with  the  required  functionality,  as  defined  by  the  customer,  and 
ality.  The  advantage  of  this  model  is  that  one  organization  has  control  over  the  development  of  both  the  core  functionality  and 


1  OEM  is  the  Original  Equipment  Manufacturer.  In  the  case  of  software  the  OEM  is  defined  as  being  the  writer  of 
the  software. 
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ality.  Again,  the  main  issue  with  this  implementation  option  is  that  an  appropriate  third  party  integrator,  one  that  is  familiar  with 
ahnology  and  the  PDT  SDK,  may  be  difficult  to  find. 
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11. Rough  Order  of  Magnitude  (ROM)  Estimates  by 

Implementation  Model 

This  section  provides  rough  order  of  magnitude  (ROM)  estimates  of  the  effort  required  to  implement  PDT  based 
on  the  models  presented  in  the  previous  section.  These  estimates  are  provided  for  comparison  purposes  only 
since  the  actual  effort  required  to  implement  PDT  is  highly  dependent  on  the  conditions  of  integration  and  the 
feature  set  selected. 

11.1.  General  Visual  Collaboration 

11.1.1.  Multi-User  Master/Slave  Synchronization  for  2  Users  -  Dumb  Display  Host 

11.1.1.1.  OEM  (Call-Fusion,  Webex,  etc.)  Integrates  Synchronization  Functionality 

•  Pros: 

o  Vendors  are  very  experienced  with  this  type  of  synchronization 

•  Cons: 

o  Secure  deployments  can  be  relatively  expensive 

•  Level  of  Effort:  Medium 

•  Risk:  Low-Medium 

•  Payoff:  Medium 

•  Priority:  Medium 

11.1.1.2.  OEM  Provides  APIs;  IDELIX  Integrates 

•  This  option  should  be  considered  since  synchronization  is  not  an  IDELIX  core  competency 

11.1.1.3.  OEM  and  IDELIX  Jointly  Integrate  Functionality 

•  This  option  should  not  be  considered  since  synchronization  is  not  an  IDELIX  core  competency 

11.1.1.4.  IDELIX  Integrates 

•  This  option  should  not  be  considered  since  synchronization  is  not  an  IDELIX  core  competency 

11.1.1.5.  Third  Party  System  Integrator  Integrates  Functionality 

•  This  option  should  not  be  considered  since  this  type  of  synchronization  is  likely  not  a  core  competency 

11.1.1.6.  IDELIX  Produces  an  Application  to  Specification 

•  This  option  should  not  be  considered  since  synchronization  is  not  an  IDELIX  core  competency 

11.1.1.7.  Third  Party  System  Integrator  Produces  an  Application  to  Specification 

•  This  option  should  not  be  considered  since  this  type  of  synchronization  is  likely  not  a  core  competency 
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11.1.2. 


Multi-User  Master/Slave  Synchronization  for  2  Users  -  Application  Synchronization 


11.1.2.1.  OEM  (Thales)  Integrates  Synchronization  Functionality 

•  Pros: 

o  Thales  familiar  with  code  since  developed  application 

•  Cons: 

o  Application  synchronization  is  very  difficult 

•  Level  of  Effort:  High 

•  Risk:  High 

•  Payoff:  Low 

•  Priority:  Low 

11.1.2.2.  OEM  Provides  APIs;  IDELIX  Integrates 

•  This  option  should  not  be  considered  since  synchronization  is  not  an  IDELIX  core  competency 

11.1 .2.3.  OEM  and  IDELIX  Jointly  Integrate  Functionality 

•  This  option  should  not  be  considered  since  synchronization  is  not  an  IDELIX  core  competency 

11.1.2.4.  IDELIX  Integrates 

•  This  option  should  not  be  considered  since  synchronization  is  not  an  IDELIX  core  competency 

11.1.2.5.  Third  Party  System  Integrator  Integrates  Functionality 

•  Cons: 

o  Application  synchronization  is  very  difficult 

•  Level  of  Effort:  High 

•  Risk:  High 

•  Payoff:  Low 

•  Priority:  Low 

11.1 .2.6.  IDELIX  Produces  an  Application  to  Specification 

•  This  option  doesn’t  make  sense 

11.1.2.7.  Third  Party  System  Integrator  Produces  an  Application  to  Specification 

•  This  option  doesn’t  make  sense 

11.2. 
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1 1 .3.  PDT  in  the  COPIanS  GIS 


11.3.1.  PDT  Enhancement  of  On-Map  Mission  Planning 

•  Level  of  Effort:  Varies 
•  Risk:  Varies 

•  Payoff:  High 

•  Priority:  High 


3.1.1.  OEM  (Luciad)  Integrates  PDT  Functionality 

Pros: 

o  GIS  application  architecture  and  code  known  well  by  OEM  vendor 

•  Cons: 

o  OEM  vendor  may  choose  not  to  participate 

o  Conflicting  priorities  in  application  development  cycle  for  OEM  vendor;  could  be  hidden  delays 
o  OEM  vendor  has  no  knowledge  of  PDT 

•  Level  of  Effort:  Med-High 

•  Risk:  High 

•  Payoff:  High 

•  Priority:  Low 


11.3.1.2.  OEM  (Luciad)  Provides  APIs  to  the  Image  Processing  Pipeline;  IDELIX  Integrates  PDT 

•  Pros: 

o  IDELIX  can  provide  PDT  knowledge  and  expertise  to  the  development  effort 
o  More  time  flexibility  for  the  customer  since  defined  project  stages 

•  Cons: 

o  OEM  vendor  may  choose  not  to  participate 

o  Highly  conflicting  priorities  in  application  development  cycle  for  OEM  vendor;  hidden  delays  likely 
o  Multiple  vendors  to  deal  with 

•  Level  of  Effort:  High 

•  Risk:  Med-High 

•  Payoff:  High 

•  Priority:  Low 


11.3.1.3.  OEM  (Luciad)  and  IDELIX  Jointly  Integrate  PDT  Functionality 

•  Pros: 

o  IDELIX  can  provide  PDT  knowledge  and  expertise  to  the  development  effort 
o  Maximum  understanding  and  knowledge  applied  to  development  effort 
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•  Cons: 

o  OEM  vendor  may  choose  not  to  participate 

o  Conflicting  priorities  in  application  development  cycle  for  OEM  vendor;  could  be  hidden  delays 
o  Multiple  vendors  to  deal  with 

•  Level  of  Effort:  Med-High 

•  Risk:  Med 

•  Payoff:  High 

•  Priority:  Med 

11.3.1.4.  IDELIX  Integrates  PDT  Functionality 

•  Pros: 

o  IDELIX  can  provide  maximum  PDT  knowledge  and  expertise  to  the  development  effort 

•  Cons: 

o  High  risk  since  OEM  vendor  may  choose  not  to  share  their  source  code 

•  Level  of  Effort:  Low-Med 

•  Risk:  Med-High 

•  Payoff:  High 

•  Priority:  High 

11.3.1.5.  Third  Party  System  Integrator  Integrates  PDT  Functionality 

•  Cons: 

o  Depends  on  experience  with  Luciad  GIS 
o  Depends  on  experience  with  PDT 

o  High  risk  since  OEM  vendor  may  choose  not  to  share  their  source  code 

•  Level  of  Effort:  High 

•  Risk:  High 

•  Payoff:  High 

•  Priority:  Very  Low 

1 1 .3.1 .6.  IDELIX  Produces  an  Application  to  Specification 

•  Pros: 

o  Single  source  Canadian  vendor 

o  Purpose  built  application  will  provide  maximum  usability 
o  Highest  degree  of  control  over  development  process 
o  No  legacy  code  to  contend  with 

•  Cons: 

o  Removal  of  current  OEM  vendor  GIS  application 

•  Level  of  Effort:  Med-High 

•  Risk:  Med 

•  Payoff:  High 
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Priority: 


Med 


11.3.1.7.  Third  Party  System  Integrator  Produces  an  Application  to  Specification 

•  Pros: 

o  Single  source  vendor 

o  Purpose  built  application  will  provide  maximum  usability 
o  Highest  degree  of  control  over  development  process 
o  No  legacy  code  to  contend  with 

•  Cons: 

o  Removal  of  current  OEM  vendor  GIS  application 

•  Level  of  Effort:  Med-High 

•  Risk:  Med-High 

•  Payoff:  High 

•  Priority:  Med-High 

11.4. 
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11.5.  PDT  in  the  COPIanS  GIS  Operating  on  a  Collaboration  Tabletop 

1 1 .5.1 .  Software  Functionality  Implementation  for  a  Table  Aware  Application 

•  Level  of  Effort:  Varies 
•  Risk:  Varies 

•  Payoff:  High 

•  Priority:  High 

5.1.1.  OEM  Integrates  Functionality 

This  option  cannot  be  considered  since  there  are  no  current  GIS  OEM  applications  for  the  MERL  table 

’.OEM  Provides  APIs  to  the  Image  Processing  Pipeline;  IDELIX  Integrates 

otion  cannot  be  considered  since  there  are  no  current  GIS  OEM  applications  for  the  MERL  table 

!M  and  IDELIX  Jointly  Integrate  Functionality 

tion  cannot  be  considered  since  there  are  no  current  GIS  OEM  applications  for  the  MERL  table 

[  Integrates  Functionality 

cannot  be  considered  since  there  are  no  current  GIS  OEM  applications  for  the  MERL  table 

'arty  System  Integrator  Integrates  Functionality 

not  be  considered  since  there  are  no  current  GIS  OEM  applications  for  the  MERL  table 

duces  an  Application  to  Specification 

o  Single  source  Canadian  vendor 
o  Purpose  built  application  will  provide  superior  usability 
o  High  degree  of  control  over  development  process 
o  No  legacy  code  to  contend  with 

•  Cons: 

o  Removal  of  current  OEM  GIS  application 

•  Level  of  Effort:  Medium 

•  Risk:  Medium  (3  phased  approach  only) 

•  Payoff:  High 

•  Priority:  Medium 

11.5.1.7.  Third  Party  System  Integrator  Produces  an  Application  to  Specification 

•  Pros: 
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o  Single  source  vendor 

o  Purpose  built  application  will  provide  superior  usability 
o  High  degree  of  control  over  development  process 
o  No  legacy  code  to  contend  with 

•  Cons: 

o  Removal  of  current  OEM  GIS  application 

•  Level  of  Effort:  Medium 

•  Risk:  Medium  (3  phased  approach  only) 

•  Payoff:  High 

•  Priority:  Medium 
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